Columbia Kermit/kermit.zip/newsgroups/misc.20000824-20010305/[e-mail] _Fri Dec 29 21:42:38 2000.msg

Internet Message Format | 2020-01-01 | 7KB

Return-Path: <[e-mail]>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
    by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA14352
    for <[e-mail]>; Fri, 29 Dec 2000 21:42:38 -0500 (EST)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA05809
    for <[e-mail]>; Fri, 29 Dec 2000 21:42:36 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id VAA28021
    for [e-mail]; Fri, 29 Dec 2000 21:24:43 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: r@your_host.com (cLIeNUX user)
Subject: Re: Converting struct tm to time_t
Date: Sat, 30 Dec 2000 02:23:17 -0000
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <[e-mail]>
To: [e-mail]

[e-mail]...
>In article <92i02v$m4u$[e-mail]>,
>Igor Sobrado  <[e-mail]> wrote:
>: Frank da Cruz <[e-mail]> wrote:
>: > In article <[e-mail]>, Kevin Handy  <[e-mail]> wrote:
>: > : Frank da Cruz wrote (about mktime()):
>: >
>: > 2. Doesn't do what you want.  "In addition to computing the calendar
>: >    time, mktime() normalizes the supplied tm structure" -- applies
>: >    timezone conversions, etc.  The problem there is, of course, we
>: >    don't know, and have no way to find out, the server's timezone, and
>: >    even if we knew it, what the rules are to convert to our own.  The
>: >    struct tm is *already* in GMT/UTC, and should not be converted to
>: >    it again.
>: >
>: > Thus the resulting file date won't be what you want.  I think the
>: > object of copying the server's MDTM is so update can work in both
>: > directions.  If we use mktime(), I think the result will have up to 24
>: > hours of randomness added or subtracted.  Am I missing something?
>:
>: As you noted, the FTP-server provides the time in UTC/GMT, all
>: Unix boxes work with that standard convention. The second (incorrect)
>: conversion to UTC is made locally by the host where C-Kermit
>: is installed because mktime(3C) supposes that the tm structure is
>: in local format, not it UTC. Why not calculate the UTC offset for
>: the time (as if it is in local format) and "correct" the time
>: either before converting it to a time_t structure or after that?
>:
>This leads only to more difficulties.  The time-related APIs are the most
>twisted and crazed ones in UNIX, and vary significantly from platform to
>platform and version to version of the OS, C library, and compiler and
>header files.  How do you find out the timezone or GMT/UTC offset?  Is it
>an API call (gettimeofday() or what?), a global long, ulong, int, short,
>etc?  A global struct timezone?  And/or is it extern time_t tzoffset?  A
>member of struct tm?  Obtained how?  And what are the units?  And can you
>believe them?  Do they or do they not account for daylight savings time?
>If not, how do we compensate?  Here's a typical man page quote:
>
>     The external long variable timezone contains the difference,
>     in  seconds,  between  GMT  and local standard time (in PST,
>     timezone is 8*60*60).  If this difference is not a constant,
>     timezone  will contain the value of the offset on January 1,
>     1970 at 00:00 GMT. Since this is not necessarily the same as
>     the  value  at  some  particular  time, the time in question
>     should be converted to a tm structure using localtime()  and
>     the  tm_gmtoff  field of that structure should be used.  The
>     external variable daylight is non-zero if and only  if  Day-
>     light  Savings  Time  would  be in effect within the current
>     time zone at some time; it does not  indicate  whether  Day-
>     light Savings Time is currently in effect.
>
>This would not be encouraging even if it applied to every platform,
>but it's only for one release of one OS.  In many OS's (e.g. BSDI) the
>variables and structs stay the same but their meaning changes from one
>release to the next.  In other OS's the structs and variables change, the
>header files move, and every other manner of obstacle can be expected.
>
>In fact, I can try to program all this, but to make it compile, link, and
>run correctly on hundreds of platforms is not going to be pleasant, as you
>can already tell by looking at the other time-related code in cku[ft]io.c.
>
>If anybody has any helpful or simplifying suggestions, I'd be glad to
>hear them.  The question is:
>
>  How to convert a struct tm (which already is expressed in GMT) to
>  a time_t which expresses the clock time in GMT (not local time) in
>  a way that is reliable (works in any timezone and takes daylight
>  savings into account) and is portable to as many UNIX platforms as
>  possible (and how to do the same things on the platforms to which
>  this portability does not extend)?  The answer (as noted previously)
>  is not mktime(), since it presumes its argument is in local time,
>  not GMT.
>
>I'll copy this to comp.unix.programmer.


Daylight savings is an arbitrary political phenomenon. A locale thing.
Plan9 recuses itself from locale issues altogether, leaving them to the
localities, with comments to the effect that no one else can cope. I don't
know if Plan9 is that way about time, but it's the same issue. The
individual Plan9 admins, in this case. I don't deal with the problem in my
little Linux distro either. Even where the tz stuff can be found, it's
horrid. I personally try to keep local non-political time on my box. And
wristwatch.

Oldtimers call what we have now "railroad time". Time used to be relative
to Town Hall or the Cathedral or what-have-you. Technology should at this
point allow us to move back toward that. Let the airlines and the
railroads and networks deal with the diffs, not you and me.

My-wristwatch-local time is of course a fantasy. GPS's are still a bit
large for that :o) Less extreme perhaps is the idea that locale support in
a systems programming language ( C ) is absurd. Plan9 mumbles something
faintly derogatory about software-by-committee concerning POSIX locale
stuff.

Bottom line; see what the problem looks like if you leave daylight savings
to the admin.

Rick Hohensee
www.clienux.com



>
>- Frank